Navigational state as used by the present invention describes “the current view of the Portal that is the result of all navigational interactions of a particular client”. The client can request (query) different views by interacting with the Portal page, e.g. by navigating to a new page. This type of interaction does not change server side state but only requests a new view of the server; it is therefore a “safe” operation in terms of HTTP. The nature of this interaction is such that the client can navigate back and forward through its recent views using the back and forward button of his browser and that clients can bookmark views and get back to them at a later point in time by invoking a browser bookmark.
One of the main features of HTTP is that it is a stateless protocol i.e. the notion of a session spanning multiple request/response interactions does not exist in HTTP. But as nearly all application scenarios require some mechanism to save their state across requests some mechanisms have emerged that allow for creating (logical) stateful sessions and that can be certainly considered as state of the art nowadays. The two most popular prior art state saving mechanisms are the following:
To initiate a logical session between the client (typically a browser) and the server, the server returns an extra “set-cookie” response header to the client containing basically name value pairs. The client stores the cookie persistently in a file and associates it with the server's URL. With each request, the client provides this cookie back to the server using the “cookie” request header. By analyzing the cookie, the server (not the HTTP server but the application or a server-side script such as a servlet or CGI) can identify the user-specific session containing the needed state information. Note that cookies also allow for maintaining state across session boundaries as the persistent cookie file on the client typically lives longer than the corresponding session on the server.
This second variant exchanges the complete state information between server and client. The server stores the state in the markup of the requested page using a hidden input file of a (HTML) form. In addition, the application makes sure that each URL in the markup of a page initiates a form submit causing the state being part of the hidden input field to flow along with the request to the HTTP server.
In today's Web applications even navigational state is mostly saved across requests using one of the outlined mechanisms. However, both approaches have some major drawbacks with regard to bookmarkability, caching, back/forward button, and indexing by search engines (“crawlability”).
Storing the navigational state in a logical server-side HTTP session (e.g. identified via a cookie) has the following disadvantages:
Browser bookmarks do not work as the navigational state kept in the server-side session has only a limited lifetime. Typically the session times out after a period of inactivity. After a session timeout, the navigational state cannot be restored on the server i.e. the server will deliver a default view on the application.
Navigating back and forward through the recent views using the back and forward button of the browser does not work. Note that the state does not get lost in that case as long as the session is maintained but the operations of the back and forward button do not take any effect on that state.
The benefits of caching (browser-side, server-side, and proxy caching) are considerably reduced as such caches typically use the URL as their cache key. The cache entries are overwritten with almost each interaction leading to a cache hit rate of almost zero.
Web search engines cannot index the site well. Search engines work by storing information about a large number of Web pages which they retrieve from the Web itself. These pages are retrieved by a Web-browser called “Web crawler” that follows every URL/URL it sees on the page (in the markup respectively).
Storing the navigational state in a hidden input field of a HTML form has less disadvantages but it also does not solve all problems summarized. Bookmarkability works as long as the respective page is cached. The back and forward button works. The caching and crawlability problem remains. Note that state management relying on hidden input fields cannot be applied in the Portal area as the mechanism requires a page-level form. However, a page level form cannot be used the markup of JSR 168 compliant portlets may also make use of HTML forms thus causing nested forms (forbidden by the HTML standard).
It is object of the present invention to provide a method, system and computer program product for efficiently encoding navigational state of a Portal avoiding the disadvantages of the existing prior art.